Skip to content

am243x_evm/am2434: initial support #87321

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Open
wants to merge 6 commits into
base: main
Choose a base branch
from
Open

am243x_evm/am2434: initial support #87321

wants to merge 6 commits into from
+1,273 −101

Conversation

natto1784
Copy link
Contributor

This patchset aims to:

  • make ti_k3 pinctrl multi-instance
  • add soc support for am2434 r5 and m4 cores
  • introduce am243x evaluation module as a board

@zephyrbot zephyrbot added area: Pinctrl platform: TI K3 Texas Instruments Keystone 3 Processors platform: TI SimpleLink Texas Instruments SimpleLink MCU labels Mar 19, 2025
@natto1784 natto1784 force-pushed the am243x branch 3 times, most recently from 1d084f5 to c2c270b Compare March 19, 2025 07:07
dnltz
dnltz reviewed Mar 19, 2025
View reviewed changes
nordicjm
nordicjm reviewed Mar 19, 2025
View reviewed changes
@natto1784 natto1784 force-pushed the am243x branch 6 times, most recently from bee4707 to 0e3f8d9 Compare March 19, 2025 09:05
@zephyrbot zephyrbot requested a review from jonas-rem March 19, 2025 09:22
@natto1784 natto1784 requested a review from dnltz March 19, 2025 09:28
m-braunschweig
m-braunschweig suggested changes Mar 19, 2025
View reviewed changes
Copy link
Contributor

@m-braunschweig m-braunschweig left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for adding the initial Cortex-R5F support. I looked at the changes for it and the main domain and found a few possible improvements that are in the single comments.

Also the NUM_IRQS and SYS_CLOCK_HW_CYCLES_PER_SEC Kconfig options need to be adjusted for this SoC. But to keep the scope of this PR limited I would suggest changing this later by splitting up the Kconfig into multiple files in a different PR.

Can you also share how you are booting the SoC and which changes you have done to the TI MCU+ SDK SBL, if you use it?

@natto1784
Copy link
Contributor Author

natto1784 commented Mar 19, 2025 •
edited
Loading

Hello @m-braunschweig

Also the NUM_IRQS and SYS_CLOCK_HW_CYCLES_PER_SEC Kconfig options need to be adjusted for this SoC. But to keep the scope of this PR limited I would suggest changing this later by splitting up the Kconfig into multiple files in a different PR.

noted

Can you also share how you are booting the SoC and which changes you have done to the TI MCU+ SDK SBL, if you use it?

I actually saw your documentation from the patchset here a few days ago: TexasInstruments#1 and I must say I am not doing it much differently. We are primarily using sbl_null and sbl_ospi to test out the zephyr ELFs. Additionally I also enable clocks for some modules from the SBL itself - for instance this allows me to use the mcu_uart0 for both m4 and r5

         status = SOC_moduleClockEnable(TISCI_DEV_MCU_UART0, 1);
         status = SOC_moduleSetClockFrequency(
                     TISCI_DEV_MCU_UART0,
                     TISCI_DEV_MCU_UART0_FCLK_CLK,
                     48000000
                     );

For now there is also the need to set the timer clock source manually if I am using a timer different from the SBL.

I appreciate your review and suggestions and will get to working on them tomorrow, might also edit this comment as I remember things.

@m-braunschweig
Copy link
Contributor

Can you also share how you are booting the SoC and which changes you have done to the TI MCU+ SDK SBL, if you use it?

I actually saw your documentation from the patchset here a few days ago: TexasInstruments#1 and I must say I am not doing it much differently. We are primarily using sbl_null and sbl_ospi to test out the zephyr ELFs.

Ok. Did you do any modifications for using sbl_ospi? Because you have the exception vector on the start of the SRAM partition of the core while I put it to 0x0 and I needed to change the bootloader for it to boot (which I don't really like).

@natto1784
Copy link
Contributor Author

natto1784 commented Mar 20, 2025 •
edited
Loading

Ok. Did you do any modifications for using sbl_ospi? Because you have the exception vector on the start of the SRAM partition of the core while I put it to 0x0 and I needed to change the bootloader for it to boot (which I don't really like).

For R5, did nothing, the vector table at the start of SRAM (0x70000000) gets relocated to 0x0 via z_arm_relocate_vector_table

For M4, you need to set the CONFIG_KERNEL_ENTRY="__start" since that is how it's configured in SBL

@m-braunschweig
Copy link
Contributor

The relocation itself wasn't the problem in my case. It was either parsing or setting the entryPoint via the DMSC-L which is why I hardcoded it. I will look at this again later to see, if it is really necessary or whether there was something else going on

@m-braunschweig m-braunschweig mentioned this pull request Apr 9, 2025
Open
glneo
glneo reviewed Apr 9, 2025
View reviewed changes
boards/ti/am243x_evm/am243x_evm_am2434_r5f0_0.dts Outdated

/delete-node/ &mbox4;
/delete-node/ &mbox5;
/delete-node/ &mbox7;
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

These should be disabled already, do you really need to delete them also?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

you are correct but I just deleted them since they cannot be used at all by r5fss0_0

glneo
glneo reviewed Apr 9, 2025
View reviewed changes
soc/ti/k3/am6x/r5/arm_mpu_regions.c
#include <zephyr/arch/arm/mpu/arm_mpu.h>

static const struct arm_mpu_region mpu_regions[] = {
#if defined CONFIG_SOC_AM2434_R5F0_0
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Could you use the more generic SOC_SERIES_AM6X_R5 here? Otherwise you will need to add this same check for all 4 R5F cores when those are added.

Copy link
Contributor Author

@natto1784 natto1784 Apr 9, 2025 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, this is a valid issue, right now there is no good way to distinguish between different cores since they are essentially seen as different "socs". Im not sure if all am6x r5 devices should have this mpu configuration We will need more discussion surrounding this.

Copy link
Contributor Author

@natto1784 natto1784 Apr 10, 2025 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@glneo I was thinking that perhaps we could split the Kconfig for different SoCs in soc/ directory, that would be cleaner imo and would also give us freedom to define to define an option like CONFIG_SOC_AM2434_R5 which would be selected for all cores. Currently the closest thing to this is CONFIG_SOC which is a string, hence not really of use with the preprocessor. All this however, would not be part of this PR.

Copy link
Contributor

@m-braunschweig m-braunschweig Apr 10, 2025 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, this is a valid issue, right now there is no good way to distinguish between different cores since they are essentially seen as different "socs". Im not sure if all am6x r5 devices should have this mpu configuration We will need more discussion surrounding this.
I think for now it should only apply to the AM2434 since it seems it wasn't needed for the other SoCs.

For the Kconfig I did these things 2 commits for splitting them up a bit at least:
siemens@abcfd08
siemens@4f75a54
(the first one splits the defconfig; the second one adds SOC_AM2434_R5F).

However I also agree we shouldn't increase the scope of this PR further. When this PR is merged I would rebase my current work on main and start sending PRs, firstly for adding the AM243x LaunchPad which includes these Kconfig changes.

Also for the MPU we should probably also do some changes later so a core can't access the SRAM region of another core.

Edit: We will start upstreaming the MSPI and Flash driver already while this is not merged yet

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is very nice, I feel that we can also split up Kconfig definitions just like you split up defconfigs, this would reduce clutter for different SoCs in the same file, but this is for later, I guess.

Also for the MPU we should probably also do some changes later so a core can't access the SRAM region of another core.

We can, I guess, mask the entire SRAM (all 8 partitions) as no access for all R-cores. The MPU configuration for that core's SRAM partition(s) can then be done in DT, making only that region accessible to that core. This would require moving the sram node from am64x_r5.dtsi to board/ DTS.

glneo
glneo reviewed Apr 9, 2025
View reviewed changes
glneo
glneo reviewed Apr 9, 2025
View reviewed changes
glneo
glneo reviewed Apr 9, 2025
View reviewed changes
@github-actions github-actions bot added the area: Timer Timer label Apr 10, 2025
@github-actions github-actions bot requested review from andyross and teburd April 10, 2025 08:30
@natto1784 natto1784 force-pushed the am243x branch 2 times, most recently from 779d955 to 10b3e8b Compare April 10, 2025 08:43
@natto1784
Copy link
Contributor Author

Can we remove the Timer label, it is there because I have temporarily added @glneo's dmtimer patch in the PR until it gets merged into main.

@natto1784 natto1784 force-pushed the am243x branch 4 times, most recently from 03a4d74 to e572bc9 Compare April 14, 2025 06:37
@m-braunschweig m-braunschweig mentioned this pull request Apr 15, 2025
Draft
@natto1784 natto1784 force-pushed the am243x branch 2 times, most recently from c777478 to 15d80d3 Compare April 23, 2025 07:16
glneo and others added 3 commits April 25, 2025 15:01
@glneo @natto1784
drivers: timer: ti_dmtimer: Do not require systick_timer node label
0e687f0 
This driver currently only supports one instance of this timer and uses
it as the system clock. The instance is selected by being the first one
listed in DT in all places except sys_clock_driver_init() where it uses
the node label "systick_timer".

This driver should be fixed to correctly support multiple instances
of this timer, and the one used for the system timer should be selected
based on a flag or alias, not based on label.

For now simply use the 0th instance like everywhere else which removes
the need to have this node labeled a special way and makes no functional
changes to current users.

Signed-off-by: Andrew Davis <[email protected]>
@natto1784
drivers: pinctrl: make ti_k3 multi-instance
f7e3c1e 
Some devices have multiple pinctrl regions; for instance, main pinctrl and
mcu pinctrl. Currently there can only be a single pinctrl instance picked
form a DT label. This patch makes the pinctrl driver initialise one
instance for each node with correct compatible string.

Signed-off-by: Amneesh Singh <[email protected]>
@natto1784
soc: ti: k3: add AM2434 support
a1eb6bd 
This patch adds SoC support and device trees for Texas Instruments AM2434
SoC. Both R5F and M4 cores are supported.

Signed-off-by: Amneesh Singh <[email protected]>
@natto1784
Copy link
Contributor Author

minor change: move SRAM MPU configuration from DT's MPU attr to arm_mpu_regions.c so as to allow unprivileged RO access to it for userspace threads.

natto1784 and others added 3 commits April 25, 2025 16:59
@natto1784
boards: reflect changes from am64x_m4.dtsi
d7a6213 
This patch reflects changes from the new am64x_m4.dtsi file.

Affected boards:
- phyboard_electra
- sk_am64

Signed-off-by: Amneesh Singh <[email protected]>
@natto1784
boards: arm: ti: k3: add am243x_evm
3af6456 
This patch adds board support for am2434_evm and am2434 SoC

Signed-off-by: Amneesh Singh <[email protected]>
@natto1784 @m-braunschweig
boards: ti: am243x_evm: add documentation
6752ae0 
Add documentation for am243x_evm and while at it, add the openocd
configuration as well.

Co-authored-by: Mika Braunschweig <[email protected]>
Signed-off-by: Amneesh Singh <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers

@glneo glneo glneo left review comments

@vaishnavachath vaishnavachath vaishnavachath requested changes

@nordicjm nordicjm nordicjm left review comments

@m-braunschweig m-braunschweig m-braunschweig requested changes

@gmarull gmarull Awaiting requested review from gmarull

@gramsay0 gramsay0 Awaiting requested review from gramsay0

@vanti vanti Awaiting requested review from vanti

@jonas-rem jonas-rem Awaiting requested review from jonas-rem

@dnltz dnltz Awaiting requested review from dnltz

@andyross andyross Awaiting requested review from andyross

@teburd teburd Awaiting requested review from teburd

Requested changes must be addressed to merge this pull request.

Assignees

@vaishnavachath vaishnavachath

Labels
area: Pinctrl area: Timer Timer platform: PHYTEC platform: TI K3 Texas Instruments Keystone 3 Processors platform: TI SimpleLink Texas Instruments SimpleLink MCU
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.
7 participants
@natto1784 @m-braunschweig @glneo @vaishnavachath @dnltz @nordicjm @zephyrbot